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(57) Abstract: A distributed network system supporting foreign exchange execution is described. The system allows customers 
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matic exchange of settlement information makes the system attractive to both customers and dealers. Embodiments of the invention 
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BACKGROUND OF THE INVENTION 

Field of the Invention 

This invention relates to the field of foreign exchange of currencies. In 
particular, the invention relates to systems, methods and apparatuses for providing 
5 improved workflow and multi-bid foreign exchange using networked computers. 
Description of the Related Art 

Background: The Foreign Exchange Market 

The foreign exchange market is considered to be the largest and most liquid 
market in the world. The Federal Reserve Bank of New York estimated, in 1998, that 
the daily turnover was around $1.5 trillion a day. See, The Foreign Exchange Market 
in the United States. Sam Y. Cross, Federal Reserve Bank of New York, available at 
<http://www.ny.frb.org/pihome/addpub/us6cm/>, p. 15, hereinafter Cross. 

Single foreign exchange transactions in the $200 million to $500 million range 
are not uncommon. Id. Further, changes in exchange rates may occur as often as 
twenty times a minute. Id. Unlike stocks and some commodities, which are market 
traded, foreign exchange is primarily an over-the-counter market. There is no such 
thing as the "price" for a particular transaction. Rather, each dealer, bank, broker, or 
other trading source, provides their rate for each transaction that is proposed to it. 

Thus, the foreign exchange market as a whole is a largely unregulated, global 
market that operates twenty-four hours a day. Some definitions will be helpful in 
understanding the market. 

Definitions 

Foreign Exchange 

The term "foreign exchange" refers to money denominated in the currency of 
another nation, or group of nations. See Cross, p. 9. As such, a person who exchanges 
money denominated in her/his own nation's currency for money denominated in 
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another nation's currency acquires foreign exchange. Id. This is true irrespective of 
the size of the transaction; the person performing the transaction; or the form of 
money being acquired, e.g. notes, bank deposits denominated in another currency, 
claims denominated in another currency, etc. The term will sometimes be referred to 
5 by the commonly used abbreviation "FX". 

Foreign Exchange Transaction 

Thus, a "foreign exchange transaction" is a shift of funds, or short-term 
financial claims, from one country and currency to another. Id. 

Foreign Exchange Market 

10 The "foreign exchange market" refers to the global network of dealers 

engaged in trading around the world. CX Cross, p. 9. 

Exchange Rate 

The term "exchange rate", sometimes referred to as a "price quote" or "rate", 
is the number of units of one nation's currency that must be surrendered in order to 
1 5 acquire one unit of another nation's currency. Id. However, at any given time there 
are multiple exchange rates for a given currency, e.g. for different buyers or dealers 
and different types of foreign exchange transactions. The term market comparable 
rate — or reference rate — will be used to refer to publicly available pricing information 
for foreign exchange transactions. 

20 Abbreviations 

A variety of common foreign exchange conventions will be used to identify 
currencies according to the commonly used three-letter abbreviation: USD = United 
States Dollar; DEM = Deutchmark; JPY = Japanese Yen; EUR = Euro; etc. Thus, 
EUR 500 refers to five hundred Euros. Similarly, the United States convention of 

25 using T+N to refer to a settlement date N days ahead of the current day will be used. 
Thus, T+2 means a settlement two days from today. 
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Payment and Settlement 

Every nation has its own payment and settlement practices. See Cross, pp 1 1- 
13. The term "payment" refers to the transmission of an instruction to transfer value 
that results from a transaction. The term "settlement" refers to the final transfer of the 
5 value specified in the payment instructions. 

Thus, when two traders enter a deal, e.g. WidgetCo buys JPY 100,000,000 for 
USD 1,000,000, spot, the traders have agreed to the terms of the transaction. Payment 
occurs when settlement instructions are transmitted. Settlement, or execution, of that 
transaction does not occur until later. In most transactions, there are two transfers of 
1 0 money value in opposite directions. 

Foreign Exchange Need 

The term "foreign exchange need" refers to a need for an amount of foreign 
exchange at a particular time. Thus, in the above example, WidgetCo had a foreign 
exchange need for JPY 100,000,000 two days hence — since spot trades settle at T+2 
15 in the United States at present. 

Programs. Modules, and Computers 

A "program" is a sequence of instructions that can be executed on a computer. 

The program may comprise source code, object code, byte code, and/or any other 

sequence of instructions that can be executed on a computer. 
20 A "computer", or computer system, refers to a computer, a group of computers 

coupled in communication, and/or some other type of computing device. 

A "module" is a logical entity comprised of one or more programs related to 

one another for providing a function. Additionally, a module can be comprised of one 

or more modules. A single module may be implemented across a number of 
25 computers. For example, in a client-server architecture, a module might be comprised 

of client side programs for execution on a client computer as well as server side 

programs for execution on a server computer. 
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Trading Modalities 

The accessibility that particular individuals have to different rates and trading 
modalities will vary greatly. In 1998, the Federal Reserve Bank of New York 
identified ninety-three major foreign exchange dealers, most of whom were 
5 commercial banks. See Cross, p. 23. In this role, they serve as intermediaries for 
corporate clients and also as market makers. Additionally, they may also trade for 
their own accounts. 

In some instances, third party brokers act on behalf of clients in the 
over-the-counter market for foreign exchange in return for a fee or commission. This 
10 is different from dealers, who will sometimes act as principals in a transaction, e.g. 
take one side of the deal. Brokers are estimated to handle about one fourth of the 
foreign exchange transactions in the United States. See Cross, p, 27. 

Until 1992, brokered business was handled over the phone. More recently, 
some electronic broker systems have gained market share. These systems include the 
1 5 Electronic Brokerage Systems (EBS) and Reuters 2000. These systems may display 
bid and offer rates being quoted by potential counter-parties. See Cross, p. 29. It is not 
possible to know the identity of a counter-party until the deal is struck. Id. 

A few very large companies have direct access to EBS and Reuters 2000. 
However, for the most part, someone in a company must make a phone call to their 
20 bank, broker, or other dealer to carry out the transaction. In recent years, some large 
dealers have rolled out single party systems to accept requests from clients. Thus, 
instead of calling the bank's trading floor, the company would dial in to a dedicated 
system to place the requests. 

Corporate Experience 

25 It is helpful to explore how the foreign exchange market works for a 

corporation. Three example corporations will be considered: CreditCardCo, a credit 
card company that accepts transactions overseas for dollar-denominated credit card 
accounts; WidgetCo, a company that has overseas operations and transactions; and 
InvestCo, an investment company that trades assets overseas. 
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CreditCardCo 

CreditCardCo is concerned about getting good exchange rates. For this 
purpose, they have several employees who place simultaneous phone calls to different 
dealers with whom CreditCardCo has relationships. The dealers give an immediate 
5 price and the employees call those prices out to another employee who writes the 
prices on a board. That employee selects the best price and instructs one of the 
employees on the phone to complete the transaction with the appropriate dealer. 

This process is relatively inefficient. First, if CreditCardCo has relations with 
twenty banks, it would not be manageable to call all of them. Second, because it is 
10 voice/phone based, the process is error-prone. As in many foreign exchange 

transactions, mistakes and misunderstandings will occur. Third, once the terms are 
agreed upon, paper slips must be matched up for settlement both at CreditCardCo and 
at the dealer's bank. This process is also subject to errors and misunderstandings. 

WidgetCo 

1 5 WidgetCo regularly needs to perform foreign exchange transactions to pay for 

operations overseas. WidgetCo had in the past gone through a telephone to the trading 
desk at their bank MegaBank. Recently, WidgetCo has begun using MegaB auk's 
dedicated system. This allows WidgetCo to place its transactions at the rate 
MegaBank is quoting at a given time. 

20 These systems are not providing "real time" quotes in the way that the 

telephone dealers were, but rather are providing a quote based on a ratio off a quote in 
a pre-loaded table. In this approach, the quote given is only as good as the table and 
the ratio specifying the extent to which the rate is to be adjusted. This system is 
desirable to MegaBank because it reduces their costs for "small," e.g. less than USD 5 

25 million transactions. In some instances, the system may allow for transfer to a live 

dealer, either by phone or chat, if the transaction size is sufficiently large. This system 
is also desirable to MegaBank because the quote is more competitive and it locks the 
client into using the bank for its foreign exchange. 
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InvestCo 

InvestCo has several mutual funds for which it trades equities for its clients. 
For example, InvestCo might have an international stock fund with holdings in Japan, 
Europe, and China. As InvestCo's managers perform trades in those stocks, foreign 
5 exchange needs will arise. 

At present, InvestCo may have a number of employees who review equity 
transactions to identify foreign exchange needs. For example, a buy on Hitachi in 
Japan today will require settlement, e.g. Japanese Yen, to be paid three days hence, 
e.g. T+3. The employees can review these equity transactions and place orders the 
10 following day, as most currencies trade at T+2. 

This is a labor-intensive process that also requires use of the approaches 
described above for CreditCardCo and WidgetCo to cany out the foreign exchange 
transactions. Additionally, there may be additional complexities involved in netting 
out transactions, properly allocating trading costs among different funds/clients, and 
1 5 providing appropriate settlement instructions. 

Existing Multi-Bid System 

Waldron Management Services, Inc. developed FX Fox for foreign exchange 
execution that provides for multiple bids. The system was implemented using a 
character terminal based program on a Digital Equipment Corporation (DEC) system 
20 running the Virtual Memory System (VMS) operating system. 

Customers and banks used dedicated phone lines to contact the system and log 
in. The system currently has approximately ten customers signed up and 
approximately twenty banks signed up. The system has been available since 1996 and 
several dozen trades a day are handled. 
25 The system is focused on transaction execution using a multi-bid framework. 

The multi-bid framework works as follows: 

1 . Customer places a transaction request over her/his dedicated connection 
using the character terminal based software interface. 
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2. System presents the request to appropriate dealers, e.g. traders representing 
banks, etc., who are currently logged in to the system. Dealers are given a 
short time window, e.g. less than 60 seconds, usually 20-40 seconds, in 
which to supply their bid. 



5 



3. At end of the time period, pending bids are presented to customer all at 
once. The system sorts bids by rate competitiveness for the customer. 



4. Customer has a short time period to accept bids, e.g. less than 1 0 seconds. 



5. If customer accepts a bid, the appropriate dealer is notified, and the other 



dealers are thanked for participating. 
1 0 This provides for a very short transaction cycle and reduces exchange risk for dealers 
who place bids. 

Several additional features bear mention. Dealers do not know whether other 
dealers are bidding — or even logged in — in order to encourage competitive quotes at 
all times. However, at any time prior to when the customer accepts a bid, a dealer can 
1 5 pull the quote. 



Requests from customers are shown only to dealers representing banks that / 
have a direct credit relationship with those customers and who are trading the \ 
appropriate currencies. Thus, if customer CI has a relationship with banks Bl and B2, ; 
but not B3. Customer Cl's requests will never be shown to bank B3. Further, if bank ; 

20 B2 does not trade the particular currency involved in a transaction request from j 

customer CI, then bank B2 will not be shown the request for bidding. _J 

In addition, the customer can further restrict the list of banks to which a given 
request is presented. This can be important when large requests are made. If multiple 
participants in the market know that a large request is coming, they may give a much 

25 less competitive bid because of their perception of risk. This risk arises from the 
practice of "front running" where participants may make trades in advance of a 
customer knowing that the subsequent trade will move prices in a particular direction. 
When fewer institutions see a request, they can break it into smaller, less visible 
pieces to reduce the effect of the trade on the market price. 
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Customers can either provide settlement instructions at the end of their trading 
session, or the customer can memorize certain types of transactions, e.g. sell Euro, 
and provide settlement instructions that are associated with that transaction. 

This system has been highly successful at offering customers more 
5 competitive rates for their transactions because the banks know they may be bidding 
against others. Further, banks enjoy the system because it allows them greater access 
to their customers* foreign exchange needs and reduces errors. For example, as with 
CreditCardCo above, if bank Bl was one of the twenty banks CreditCardCo dealt 
with, bank Bl might only be asked to give quotes in 10 out of the company's 50 daily 
10 transactions. With a multi-bid system, bank Bl has a shot at bidding on all 50 of the 
transactions. 

Conclusion 

The prior approaches to supporting foreign exchange transactions have used 
proprietary systems and approaches that tend to favor established dealers over smaller 
15 dealers and customers. Prior approaches have not provided workflow features. Prior 
approaches have not provided for interoperability as a component of a larger system 
in which foreign exchange order execution is a component Accordingly, what is 
needed is a system for multi-bid foreign exchange workflow automation. 
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SUMMARY OF THE INVENTION 

A distributed network system supporting foreign exchange execution is 
described. Embodiments of the invention allow customers to receive competitive 
price quotes to meet foreign exchange needs from dealers through a multi-bid foreign 
5 exchange execution process. 

The multi-bid foreign exchange execution process encourages dealers to place 
more competitive price quotes. However, it simultaneously increases the number of 
price quote requests that dealers receive from their customers. 

The result is a win-win situation. Lower handling costs are also afforded by 
10 fewer errors caused by incorrect hearing or transcription and automatic exchange of 
settlement information. Therefore, embodiments of the invention are desirable to both 
customers and dealers. 

Several aspects of embodiments of the invention will now be considered in 
greater detail. 

15 Foreign Exchange Execution over a Network 

Some embodiments of the invention support dealer computers communicating 
via a network with customer computers. The dealer computers respond to requests for 
bids, e.g. price quotes, for foreign exchange needs from customers with price quotes. 
The customer computers place requests for bids for foreign exchange needs and 

20 respond to price quotes received from dealer computers. A transaction server enforces 
time limits associated with multi-bid foreign exchange execution between customer 
computers and dealer computers. Additionally, the transaction server monitors latency 
across the network. 

The dealer computers may be operated by dealers, e.g. traders operating on 

25 behalf of banks or other institutions bidding to meet customer foreign exchange 
needs. However, the dealers may program the dealer computers with one or more 
rules to automatically respond to one or more requests. 
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The customer computers may be operated by customers, e.g. traders operating 
on behalf of a management or other institution with foreign exchange needs. 
However, the customers may program the customer computers with one or more rules 
to automatically place requests and/or respond to price quotes. 
5 The dealer computers may correspond to two or more different legal entities. 

Accordingly, the customer computers are able to receive price quotes from different 
banks or other institutions at a single time. 

Similarly, the customer computers may correspond to two or more different 
legal entities. Accordingly, dealers are able to receive requests from different 
1 0 customers on a single network. 

The network may be a public network, e.g. the Internet, a private network, 
and/or a combination of different networks. The network may have a number of 
network devices, e.g. routers, switches, etc., that control the flow of data across the 
network. According to some embodiments of the invention, the transaction server 
1 5 sends instructions to the network devices in response to the latency information. 

For example, if the transaction server monitors that the latency between the 
dealer computer Dl and the transaction server has exceeded a predetermined 
threshold, the transaction server could instruct a router to send packets from the dealer 
computer Dl to the transaction server over a different path or to instruct the 
20 application on the dealer computer to cormect to an address of a nearer proxy for the 
transaction server. 

Some embodiments of the invention may be deployed across a network having 
a mixture of guaranteed quality of server (QoS) and non-guaranteed QoS connections. 
Further, such embodiments may be deployed using points of presence coupled to the 
25 transaction server by guaranteed QoS connections while the dealer computers and 
customer computers are coupled to the points of presence by non-guaranteed QoS 
connections. 

This network topology significantly reduces the costs normally associated 
with using guaranteed QoS links as there are fewer long distance links. However, 
30 when combined with the latency monitoring features of embodiments of the 
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e.g. a predetermined latency threshold. 

Additionally, embodiments of the invention may make use of encryption at the 

transport layer of the network protocol, e.g. using the transport layer security (TLS) 
5 protocol — formerly known as the secure sockets layer (SSL) protocol. Additionally, 

embodiments of the invention may use additional authentication methods to allow 

specific customers and dealers to identify themselves to the transaction server via 

their respective customer and dealer computers. 

Embodiments of the invention may extend the time limits for multi-bid 
0 execution according to latency characteristics for the network. For example, if from 

monitoring the latency, the transaction server identifies an average latency of 200 ms, 

then responses received within the appropriate time limit plus 200 ms could be 

accepted. 

The customer and dealer computers may take a number of forms. For example, 

5 handheld computers with wireless networking could serve as customer — or dealer — 
computers. Further, some embodiments of the invention support as customer and 
dealer computers, computers providing a standard web browser with support for 
Java(TM) and/or Javascript(TM), an Internet kiosk, a personal computer with 
Microsoft(TM) Internet Explorer(TM) and an Internet connection, etc. 

D In some embodiments of the invention, the transaction server supports 

automatic transfer of settlement information between counter parties to a transaction, 
e.g. a customer and the dealer who's offer that customer accepted. This may occur 
automatically, e.g. after the customer accepts a dealer's offer, the settlement 
information could be transmitted. 

5 Embodiments of the invention can support a broad range of standard — as well 

as non-standard — foreign exchange transaction types. Some embodiments of the 
invention support one or more of the following transaction types: spot transactions, 
outright forward transactions, spot-next transactions, tom-next transactions, 
spot-a-week transactions, spot-two-weeks transactions, spot-forward transactions, 

3 odd-date transactions, forward-forward transactions, long date transactions, and/or 
currency swap transactions. 
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Uses of embodiments of the invention for reducing currency risk in electronic 
commerce will now be considered. 

Reducing Currency Risks in Electronic Commerce 

Some embodiments of the invention support integration with electronic 
5 commerce to reduce currency risk. Accordingly, when a party (e.g. a buyer) conducts 
a transaction with another party (e.g. the seller) using a commerce site, the system can 
identify foreign exchange needs arising from the transaction. 

As a result, a message can be sent to an appropriate party, e.g. the buyer, 
offering to provide foreign exchange execution. For example, on a transaction 
1 0 confirmation web page presented to the buyer, an area could indicate that 

"EUR 5,000,000 will be needed Friday" together with a button to allow the buyer to 
respond signaling her/his interest in having that foreign exchange need met with 
competitive price quotes. 

The commerce site could then submit the foreign exchange need for multi-bid 
15 execution and present received price quotes to the buyer. The buyer in turn could 
accept — or decline — the presented offers. 

The effect of this is to eliminate currency risk from transactions as the foreign 
exchange needs can be met in conjunction with transaction completion. 

Additional embodiments of the invention may support real-time presentation 
20 of the best price quote for completing a transaction. Accordingly, a buyer would see 
the seller's price for a transaction in her/his preferred currency prior to transaction 
completion, e.g. prices for items Euros. As the multi-bid execution process time limit 
for responding to a quote expires, new quotes could automatically be requested. This 
approach allows buyers to view the commerce site in their preferred currency and 
25 conduct transactions in real-time without currency risk. 

Embodiments of the invention may deployed for business-to-business 
commerce as well as business-to-consumer commerce. 

Embodiments of the invention may use the credit relationship between the 
commerce site and dealers to determine distribution of requests to dealers 
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participating in the multi-bid foreign exchange execution process. Other 
embodiments, may use the credit relationship between the purchaser, e.g. the buyer, 
and the dealers to determine distribution of requests. The first approach has the 
advantage of allowing smaller companies to use the credit relationship of the 
5 commerce site to gain wider distribution of the requests. 

Some embodiments of the invention, automatically transmit settlement 
information from the buyer to the dealer and vice versa. 

Several user interface functions provided by embodiments of the invention 
will now be considered. 

10 User Interface Functionality 

Embodiments of the invention use a graphical user interface to allow 
customers and dealers for foreign exchange execution. Embodiments of the invention 
may be provided as a single set of one or more programs for both customers and 
dealers, thus enabling customers to act as dealers and vice versa. 
1 5 First, the customer user interface will be considered. 

Customer 

The interface for customers supports a graphical tasks list. The tasks list 
contains foreign exchange needs that the customer has to execute. Concurrently, a 
second visual indication can be provide to allow requests for multi-bid foreign 
20 exchange execution of tasks can be provided. 

For example, when a customer clicks on a task in the tasks list, the second 
visual indication could allow the customer options relating to submitting a request for 
the foreign exchange need corresponding to the task. Thus, if the task was to buy 
. EUR 5,000,000, spot, the second visual indication might include options to customize 
25 the request for price quotes, e.g. bid the request as a two-way quote, hedge currency 
risk by requesting the transaction as part of a currency swap, etc. 

Once execution occurs, the tasks list is updated. For example, completed tasks 
may be removed from the tasks list. Similarly, completed tasks could be sorted to the 
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bottom of the tasks list, have their coloring changed, have an icon assigned, etc. This 
assists customers in fulfilling all of the foreign exchange needs she/he has been 
assigned to complete in a given period in an integrated fashion relative to the 
execution. The tasks list may be imported from an outside data source, e.g. an 
5 enterprise resource planning (ERP) system, a spreadsheet, a database, and/or some 
other source. 

Additionally, embodiments of the invention may support a graphical user 
interface to price quote selection. This can be provided with a third visual indication 
for displaying received price quotes. Conventions such as sorting the price quotes in 
1 0 order of cost, e.g. with the least cost price quote at the top, showing the dollar cost of 
each quote relative to the least cost price quote, and/or assigning a default keyboard 
shortcut to select the least cost price quote can be used. 

Still more options can be provided to adjust the shading, coloring, and/or icons 
associated with price quotes. Some of these settings may be defined from customer 
15 defined rules, e.g. "Display all price quotes more than USD 1,000 from the least cost 
quote in gray." These rules may reflect customer preferences, e.g. "I like my best 
quotes in bright red", as well as customer requirements, e.g. "I am supposed to buy 
from MegaBank if their quote is within 3% of the best quote." 

Other embodiments of the invention may assign icons, e.g. weather icons from 
20 sunny to rainy, to price quotes to indicate the relative "badness" of a quote when 
compared to the least cost price quote. 

Additionally, the graphical user interface may include a timer for the customer 
to show her/him how much time she/he has to accept the price quotes. 

Now, the dealer user interface will be considered. . 

25 Dealers 

Embodiments of the invention support a graphical user interface for dealers 
designed to allow for a high volume of executions. As such, a number of visual 
indications can be provided on the display area. Bach of them for receiving requests 
from customers and allowing the dealer to respond to that request with price quotes. 
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The visual indications can be distributed over the display area so as not to 
overlap one another. This prevents the need to toggle, or switch, between different 
views, screens, monitors, etc., to handle several transactions at once. For example, 
some embodiments of the invention provide three simultaneous visual indications. 
5 Each of the visual indications may also be assigned a keyboard shortcut to 

permit rapid selection of a visual indication. This reduces the amount of mouse 
movement needed to switch the keyboard input focus among the visual indications. 
Thus if the dealer is working in a first visual indication and a second request comes in 
on a second visual indication, the dealer can easily switch the keyboard focus to allow 
1 0 her/him to provide a quote for the second request without needing to use the mouse. 

Additionally, embodiments of the invention automatically assign incoming 
requests to visual indications in the plurality of visual indications. For example, if a 
particular visual indication is in use, it will not be assigned a new request until the 
earlier request is finished, e.g. the customer accepts the offer, time runs out, or the 
1 5 customer accepts a different dealer's offer. 

In order to assist the dealer in responding to requests, embodiments of the 
invention may supply the most recent quote given by the dealer along with the age of 
the quote, e.g. BUY EUR 0.9950 (31 seconds ago). 

Some embodiments of the invention may allow the dealer to develop one or 
20 more rules for implementing preferences and practices as well as for automatically 
responding to quotes. For example, the dealer could develop one or more rules to 
highlight her/his preferred customers' bid requests with an icon. Similarly, the dealer 
could program automatic price quote responses for small dollar volume transactions, 
e.g. automatically use my last quote — if less than sixty seconds old — times 0.0005 on 
25 transactions with a total value less than USD 1 00,000, etc. This allows the system to 
allow dealers to respond most competitively on quotes that are most relevant for them. 

Embodiments of the invention supporting workflow automation of foreign 
exchange will now be considered. 
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Workflow Automation Aspects 

Many corporations, or other institutions, carry out transactions throughout the 
world to meet their business goals. These transactions may be recorded in one or more 
systems such as enterprise resource planning (ERP) systems. Embodiments of the 
5 invention support identification of foreign exchange needs from the transaction 
information in those systems for workflow completion of the foreign exchange 
execution. 

Accordingly, embodiments of the invention can receive tasks from a computer 
system, e.g. the company's ERP system. These tasks each correspond to a foreign 
10 exchange need generated from the transactions recorded in the computer system. This 
task list can be generated by a single action, e.g. a button click in the customer user 
interface described above, or from an automatic process that periodically causes 
transmission of tasks. 

A user interface supporting tasks presentation can be used to allow customers 
15 trading on behalf of the company to bid out the foreign exchange needs for 
competitive execution through a multi-bid process. 

Then in response to a single action, e.g. a button click, the information about 
all executed transactions — including settlement information — can be provided to 
another computer system, e.g. back into the ERP system or into a foreign exchange 
20 settlement system. 

The process may include the aggregation of foreign exchange needs across 
multiple entities within the company while preserving cost allocation for execution. 
This tends to increase the total value of each foreign exchange transaction because it 
will correspond to several smaller transactions; and that in turn leads to more 
25 competitive price quotes. Further, because cost allocation information can be 

preserved, the aggregation can occur across distinct entities within the company. 

The flow of settlement information through the process also simplifies the 
workflow. That is because, after execution of the transaction, the customer's counter 
party can be sent the settlement information associated with a task and receive the 
30 counter party's settlement information. Thus, any settlement module processing the 
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executed transaction will have all of the information needed to settle the transaction 
without the need for external matching of information between the customer's 
settlement system and the dealer's settlement system. 



4 
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BRIEF DESCRIPTION OF THE FIGURES 

Fig. 1 illustrates a multi-bid workflow automation environment and the flow 
of work according to one embodiment of the invention. 

Fig. 2 is a process flow diagram for the flow of work according to one 
5 embodiment of the invention. 

Fig. 3 shows the functional components of the foreign exchange execution 
module according to one embodiment of the invention. 

Fig. 4 illustrates a user interface provided to customers according to one 
embodiment of the invention. 
1 0 Fig. 5 is a process flow diagram illustrating the multi-bid execution process 

used by embodiments of the invention. 

Fig. 6 illustrates a user interface provided to dealers according to one 
embodiment of the invention. 
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A. Introduction 

A system for multi-bid foreign exchange workflow automation is described. 
The description is organized as follows. An overview of the foreign-exchange 
workflow is provided together with a discussion of the component processes. 
25 Then, a more detailed discussion of the foreign exchange execution module 

follows with an examination of the user interface provided to customers and dealers 
along with a discussion of several provided features. 

Next, the network and back end environment supporting the foreign exchange 
execution module is described. 
30 A discussion of the workflow process for three example corporations follows. 

Then, features provided by different embodiments of the invention are 
discussed in greater detail. 

B. The Foreign Exchange Workflow 



35 



Turning first to the description of the foreign exchange workflow, Figure 1 
illustrates the multi-bid workflow automation environment and the flow of work. 
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Figure 2 is a process flow diagram for the flow of work. The environment and 
workflow described can significantly lower the costs associated with satisfying 
foreign exchange needs for a company. 

For clarity of explanation, the entities shown in Figure 1 will be described in 
5 connection with the workflow process of Figure 2f 

The starting point is a management 100 that may include one or more logical 
entities, e.g. entity 102 and entity 104. The management 100 may represent a 
corporation, an individual, and/or some other type of management structure. The 
entities within the management, e.g. entity 102 and entity 104, may be divisions, 

10 accounts, departments, clients, and/or some other component on behalf of which the 
management 100 is acting. 

Some examples may clarify the distinction. If the management 100 represents 
InvestCo, a hypothetical mutual fund company, the entities may correspond to distinct 
funds managed by InvestCo. Similarly, if the management 100 represents WidgetCo, 

15 a hypothetical company with international operations, the entities may correspond to 
divisions within the company. 

First, at step 200, the management 100 executes one or more transactions on 
behalf of the entities 102-104. The transactions for the entity 102 are shown as 
transactions 106A-C. The transactions for the entity 104 are shown as transactions 

20 1 06D-E. The transactions 1 06A-E represent transactions made for the respective 

entities in a given time period, e.g. today, this morning, yesterday, etc. Examples of 
transactions include purchases and sales of assets, purchases and sales of equity 
instruments, expenses due, payments received, and/or other types of non-foreign 
exchange transactions. For example, the transaction 106A may represent a sale of a 

25 Japanese stock. Similarly, the transaction 106D may represent a lease payment. 
Next, at step 202, the foreign exchange needs are ascertained and 
aggregated — or netted out — additionally, settlement instructions can be associated 
with the foreign exchange needs. This is shown by the arrows 107 in Figure 1. The 
process of step 202 leads to the identification of foreign exchange needs 108A-C. The 

30 automation of this process simplifies the identification of needs and can significantly 
reduce trading costs by allowing aggregation of needs across multiple entities. 
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As shown in Figure 1, step 202 can be repeated hierarchically to aggregate 
needs across the entities. This can also ensure proper allocation of trading costs across 
entities. Table 1 shows example transactions that might correspond to the transactions 
106A-E. Table 2 shows the foreign exchange needs for each entity as generated 
5 according to the process of step 202. 



Transaction 


Detail 


Transaction 106 A 


Sell 100 Shares JCol stock on Japanese market for JPY 26,000 / 
each; JPY 4000 commission. 


Transaction 106B 


Buy 500 Shares ECol stock on European market for EUR 190.0 / 
each; EUR 50 commission. 


Transaction 106C 


Pay lease payment on Japanese office facilities, JPY 1,000,000. 


Transaction 106D 


Sell 400 Shares ECo2 stock on European market for EUR 191.0/ 
each; EUR 50 commission. 


Table 1 



Need 


Comment 


Entity 102 


Sell JPY 1,604,00; T+3 


Derived from transaction 106A and 
transaction 106C. 


Buy EUR 95,050; T+3 


Derived from transaction 106B. 




Entitv 104 


Sell EUR 76,450; T+3 


Derived from transaction 106D 


Table 2 



As seen in Table 2, the initial aggregation was on a per entity basis. If step 202 is 
repeated, aggregation can be performed across entities to net out the transactions in 
Euros to a BUY 18,600 needed at T+3. Allocation information can be saved to keep 

1 0 track of the relative contribution of each entity to that net foreign exchange need. 

The costs can be allocated among entities as appropriate to meet the fiduciary 
duties of those entities. One approach is to look at the magnitude of each entities 
contribution relative to the sum of the magnitudes. For example, if entity A had to 
BUY 1,000,000 EUR and entity B had to SELL 500,000 EUR, even though the net 

1 5 transaction amount is BUY 500,000 EUR, the cost allocation could be 2/3 entity A 
and 1/3 entity B. This would be true irrespective of whether the individual 
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transactions were BUY or SELL since the ratio of 1,000,000 / 1,500,000 would not 
change. Still other approaches may be used. 

The settlement information can be taken from lookup tables and/or databases 
established by the management 100 with information on a per entity basis if needed. 
5 Additionally, in some embodiments, the settlement information can be extracted from 
a settlement module (e.g. the settlement module 1 16) which is used by the 
management to handle settlement of foreign exchange transactions. 

Next, at step 204, a single click can cause the foreign exchange needs, together 
with any associated settlement information and/or cost allocation information, to be 

10 transferred to the foreign exchange execution module 1 12 as tasks. This is shown by 
the arrow 1 10 in Figure 1. In some embodiments, the tasks together with settlement 
information and cost allocation information are transmitted in an extensible markup 
language (XML), a comma separated value (CSV) format, a database format, a 
remote invocation, and/or some other format. The transmission may occur over a 

15 network, e.g. using a hypertext transfer protocol (HTTP) with, or without, transport 
layer security (TLS) protocol — formerly known as secure sockets layer (SSL) 
protocol — to the foreign exchange execution module. In other embodiments, the 
information may be transmitted via file transfer protocol (FTP), electronic mail, 
and/or some other format. 

20 In some embodiments, the single click is initiated on one or more computer 

systems at the management 100, e.g. to "push" to foreign exchange module 1 12. In 
some embodiments, the single click is initiated from within the foreign exchange 
module, e.g. from a user interface to "pull" from the management 100. In some 
embodiments, the step 202 and the step 204 can both occur in response to the single 

25 click. 

The exports could also be automated by configuring one or more computer 
systems at the management 100 to cause the generation of foreign exchange needs 
(e.g. the foreign exchange needs 108C) via step 202 and the export via step 204 on an 
automated basis, e.g. hourly, at the end of trading, daily, once a week, etc. The timing 
30 can be selected based on the business needs of the management 100. Factors the 
management 100 can consider include, for example, the level of currency risk the 
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management 1 00 wishes to take versus the advantage to the management 1 00 of lower 
costs through netting out transactions for execution at lower cost 

Once the information is transmitted at step 204, tasks can appear in the foreign 
exchange execution module 1 12 at stop 206. A more detailed discussion of the foreign 
5 exchange execution module 1 12 appears below. Note that the module handles task 
presentation 120 and multi-bid execution 122. Once a task is complete, e.g. the 
foreign exchange transaction has been executed to meet a particular foreign exchange 
need, there is a visual indication of task completion at step 208; see below for more 
details. 

10 In some embodiments of the invention, the foreign exchange execution 

module 112 presents a graphical user interface (GUI) on a computer system to a 
person working on behalf of the management 100 to execute tasks, e.g. a customer. 
Similarly, dealers, e.g. persons operating on behalf of banks, may have a GUI to allow 
bidding for requests from the foreign exchange execution module 1 12. In some 

1 5 embodiments, the foreign exchange execution module 1 12 can operate both for 
customers and dealers. 

Finally, at step 210, after a single click is received in the foreign exchange 
execution module 1 12, the executed transaction information for completed tasks is 
transmitted to the settlement module 1 16. This is shown by the arrow 1 14 in Figure 1 . 

20 In some embodiments, the foreign exchange execution module is programmed to 
automatically transmit information about completed tasks to the settlement module. 
The specific configuration will depend on the business needs of the management 100. 

In some embodiments, the information is transmitted using a format similar to 
those used at step 204. The information, however, now includes information received 

25 when the transaction was executed. For example, the information could include the 
other party's settlement information, the agreed upon price, comments from the 
trader, performance evaluation of the execution by the trader relative to the offered 
prices, and/or other relevant information for completed foreign exchange transactions. 
The relative performance information can provide the management 100 a 

30 valuable tool to measure the quality with which their agents are executing foreign 
exchange transactions using the foreign exchange execution module 1 12. For 
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example, if the bids received for a transaction were (1) EUR 1 .0500 / USD 1 .00 and 
(2) EUR 1.0490 / USD 1.0000, and the user of the foreign exchange execution 
module 1 12 selected bid number one for a purchase of EUR 1,000,000, the cost of the 
user's selection versus the lowest cost option could be shown, e.g. USD 1,000. 
5 Still other infomiation could be included, e.g., average quote, median quote, 

and/or other information relating to the transaction. Additionally, the relative 
performance information may be aggregated to include overall performance for the 
user over a given time period. Alternatively, other computer programs and computer 
systems can be used to assess overall performance using the relative performance 

10 information transmitted from the foreign exchange execution module 1 12. Examples 
of other metrics that may be available include quotes from third party price feeds and 
other quotes being offered in the system for similar transactions. 

Note also that embodiments of the invention may be designed to distribute 
tasks across multiple users acting on behalf of the management 100. In these 

1 5 instances, the management 100 will have multiple agents acting on their behalf, 

possibly simultaneously, via access to the foreign exchange execution module 1 12. As 
part of step 204, the tasks can be distributed across the various agents for the 
management 100. The distribution can occur either based on one or more rules 
implemented in the computer systems of the management 100, or based one or more 

20 rules established by the management 100 in the foreign exchange execution module 
112. 

The settlement module 116 can be provided by companies other than the 
provider of the foreign exchange execution module 112. The settlement module may 
be a portion of existing back office systems available at the management 100. 
25 Examples of software products that could be used as the settlement module 1 16 might 
include Swift and DTC. Once the settlement module 116 completes processing, 
update information can be sent back to the management 100 as shown by arrow 118. 

Now, the GUI provided by embodiments of the invention to customers and 
banks will be considered in greater detail. 
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C. Foreign Exchange Execution Module 

As discussed above, the foreign exchange execution module 1 12 can provide a 
graphical user interface (GUI) to allow users to interact with the system. 

In the most situations, there are two distinct types of users: customers, e.g. 
5 traders acting on behalf of the management 100 according to the scheme shown in 
Figure 1, and dealers, e.g. traders acting on behalf of banks or other institutions 
bidding to meet customer foreign exchange needs. In some embodiments of the 
invention, users can act both as customers and dealers. This can allow for inter- 
corporate or inter-dealer trading. 
10 First, the system architecture for foreign exchange execution module will be 

considered. Next, the customer user interface will be considered. The multi-bid 
process will then be considered. Lastly, the dealer user interface will be considered. 

System Architecture for Module 

Figure 3 shows the functional components of the foreign exchange execution 
15 module according to one embodiment of the invention. This could be used to provide 
the foreign exchange execution module 1 12 and implement the features described 
below. 

The following lists the elements of Figure 3 and describes their 
interconnections. Figure 3 includes a display logic 300, a client network logic 302, a 

20 network 304, a server network logic 306, a presentation logic 308, a business logic 
3 1 0, and a database 3 12. The display logic 300 is coupled to the client network logic 
302. The network 304 is coupled in communication with the client network logic 302 
and the server network logic 304. The server network logic 306, the presentation logic 
308, the business logic 310, and the database 312 are coupled one to another in the 

25 order listed. 

The following describes the use of the elements of Figure 3. The foreign 
exchange execution module is designed according to the client-server model in the 
configuration shown. Different embodiments of the invention may include different 
distributions of components between the client side and the server side. 
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In the configuration shown, the client side includes the display logic 300 
together with the client network logic 302. The display logic can be implemented with 
a mixture of extensible markup language (XML); Java(TM) applets; Javascript(TM); 
as a client-side application, e.g. native Windows(TM) programs; using static or 
5 dynamically linked libraries; and/or as a combination of the above approaches. For 
example, in some embodiments of the invention, the client side user interface is 
supported using a standard web browser, e.g. Internet Explorer(TM), Netscape 
Navigator(TM), etc., together with XML, Java(TM), and Javascript(TM). 

The client network logic 302 can be implemented in a similar fashion to the 
10 display logic 300. The client network logic 302 provides communication access 
between the client-side and the server-side over the network 304. In some 
embodiments, the client network logic 302 and the display logic 300 are implemented 
in a single program, applet, library, and/or other implementation. 

The client network logic 302 may support a Transport Layer Security (TLS) 
15 protocol (formerly known as the Secure Sockets Layer (SSL) protocol) for secure, 
authenticated communications across the network 304 using an application protocol 
such as hypertext transfer protocol (HTTP), other well-known protocols, and/or a 
proprietary application protocol. 

Depending on the implementation for the display logic 300, different client- 
20 server communication approaches might be available. For example, if the display 
logic 300 is implemented using one or more Java(TM) applets, the remote method 
invocation (RMI) might be used across a TLS protocol link for communication. 

The network 304 may be a public network such as the Internet; a guaranteed 
quality of service (QoS) network, e.g. a private packet switched network; a virtual 
25 private network implemented on a public network; a wireless network, and/or some 
other type of data network. Additionally, the network 304 may connect to load 
. balancing devices to allow the elements 306-3 12 to be distributed across multiple 
computer systems. Some of the network and security issues relating to the foreign 
exchange execution module 1 12 are described in greater detail in the section 
30 tc Network and Back End Environment," below. 
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The server network logic 306 provides the counterpart to the client network 
logic 302 and should support protocols used by the client network logic 302, 
including the TLS protocol when used to secure the communication channel. The 
server network logic 306 may be implemented as one or more programs. 
5 The presentation logic 308 and the business logic 3 10 are separate components 

for design purposes. The presentation logic 308 controls the presentationof 
information to customers and dealers accessing the foreign exchange execution 
module through the display logic 300. The business logic 310 enforces the business 
rules for the system, e.g. the system behavior, the multi-bid execution process, the 

1 0 handling of requests, etc. The two components allow for a clean distinction between 
the business rules implemented in the business logic 310 that is separate from design 
choices for presenting that information in the presentation logic 308. The two 
components may be combined in some embodiments of the invention. The 
presentation logic 308 and the business logic 3 10 may be implemented as one or more 

15 programs. 

The database 312 can provide persistent storage for the presentation logic 308, 
the business logic 310, and, if appropriate, the display logic 300. 

Additionally, in some embodiments of the invention, transaction boundaries 
where atomicity of access to the database 312 should be enforced are kept in stored 
20 programs — also called procedures in database terminology — in the database 312. 
Some embodiments of the invention use databases from Oracle Corporation, of 
Redwood City, California, to provide the database 312. 

Some of the business rules that may be enforced by the business logic 310 
include rules limiting distribution of requests according to credit availability between 
25 trading parties, rules to enforce time limits associated with the multi-bid process, rules 
limiting distribution of requests to appropriate counter-parties based on the currency 
involved, and/or additional rules. Different business rules enforced by the system will 
be discussed throughout the remainder of the document. 

We now turn to the display logic 300 from the customer perspective and the 
30 dealer perspective. 
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Customer User Interface 

Figure 4 illustrates a user interface provided to customers, e.g. traders acting 
on behalf of the management 100, according to one embodiment of the invention. 
This interface allows for rapid multi-bid execution to satisfy foreign exchange needs 
5 as part of a foreign exchange workflow. 

The graphical user interface can be provided by the display logic 300 in 
conjunction with the presentation logic 308 and the business logic 3 1 0. The interface 
is shown in Figure 4. The display 400 may comprise a physical display or a region on 
a physical display such as a window. The display 400 is shown with various interface 
10 components. There are four main components according to some embodiments of the 
invention: the tasks list 402, the task detail 404, the request choices 406, and the bids 
408. Each could be displayed as separate windows or as part of a larger single 
window. In some embodiments, the position of the user interface elements can be 
changed and, where appropriate, saved for use in later sessions. 
15 Several other interface components may be present on the display 400; these 

include menus; button bars; pricing information, e.g. from a data feed to show quotes 
being offered elsewhere; reporting options; and/or other content. For example, the 
customer might select a button in a button bar to produce a report showing executed 
trades and confirmation information. Another button might cause the one-click 
20 transmission of transaction information of step 212. 

The usage flow is from task presentation 120 to multi-bid execution 122 for 
each task. Tasks can be selected one at a time from the task list 402, e.g. the task 410 
could be selected. The task 410 is then displayed in greater detail in the task detail 
404. 

25 Embodiments of the invention can use coloring, shading, and/or icons to 

distinguish task status, e.g. executed, important, handle tomorrow, etc. See "Tasks 
List Details/' below, for more detail. 

One or more options may be available in the GUI to further customize the 
tasks list 402, e.g. what is shown in the list view. For example, the system default 

30 setting may be to list the currency and the type of transaction in the list, e.g. EUR 
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BUY, JPY SELL, etc. However, the customer may further refine the display to 
include additional information. 

In some embodiments of the invention, the task detail 404 can appear in the 
tasks list 402 when the user clicks an expand, or a disclosure, icon next to a task 
5 summary. For example, a disclosure triangle icon could be used to allow a user to 
scan details in place instead of using a separate region such as the task detail 404. 

The customer reviews the task detail 404. The customer may make decisions 
about whether or not she/he wants to complete the task at the present time. For 
example, the customer may be aware of a trend in the Euro that would make it 
10 advisable to wait until after a crucial announcement before making a trade. In that 

case, the customer can simply select another task from the list. Similarly, the customer 
may wish to restructure the task into multiple foreign exchange transactions to hedge 
currency risk. 

The customer uses the request choices 406 component to specify her/his 
15 request. As a default option, the foreign exchange execution module 1 12 can pre-fill 
options into the request choices 406 based on the task. For example, a task to BUY 
JPY 10,000,000, spot, could be pre-entered into the request choices 406 in suitable 
user interface elements. The customer could then modify those values as needed. 

For example, the customer might place the request as a two-way bid request so 
20 that bidding dealers would not know whether the customer was a buyer or seller of, in 
this example, Yen, but would have to give the customer two price quotes, one for 
buying and one for selling Yen. The multi-bid process as implemented by 
embodiments of the invention is described in greater detail below. 

Bid Display Details 

25 Embodiments of the invention make use of the graphical user interface to help 

customers better understand the different bids presented. Specifically, the bids 408 
component can display received bids in a table, scrolling list, or other formatted visual 
indication. For example, in Figure 4, the bids 408 shows two bids, the bid 414 and the 
bid 416. 
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In the configuration shown, the source of the bids, the exchange rate, a dollar 
amount cost comparison to the best bid, and an accept button are shown for each bid. 
In some embodiments, the source may be omitted, e.g. if counter party information is 
being kept confidential until after transaction acceptance. 
5 In some embodiments of the invention, the best rate quote is presented at the 

top of the list and a short-cut key, e.g. "A" or "Control-1", is available to allow rapid 
selection of the best rate. In other embodiments, each bid is assigned a letter or 
number that is shown in the screen next to the bid. To select a bid, the customer can 
press the corresponding letter or number. 

1 0 The display of a dollar amount cost compared to the best bid is useful for 

allowing customers performing trades to quickly evaluate the difference between rate 
quotes. For example, rate quotes of 1.4004 and 1.4005 for buying EUR 1,000,000, 
spot, are very similar. However, it is virtually impossible for a human to compute the 
dollar difference for taking the slightly higher quote in just a few seconds. 

15 Accordingly, embodiments of the invention could show that the 1 .4005 rate would 
cost USD 1,000 extra, etc. 

Additionally, some embodiments of the invention make use of colors, or 
shading, to identify bids in different tiers relative to the best rate. For example, darker 
colors could be used for bids with rates that are more than N%, either in the quote or 

20 the dollar difference, from the best rate. The exact percentage could be set by the 

customer, the management 100, and/or through system default rules. For example, the 
management 100 might configure the system to color bids 10-20% out yellow and 
20%+ out red. This would help management 100 direct its trading employees, e.g. the 
customer, to select better bids. 

25 Some embodiments of the invention display a timer 4 1 8 to allow the customer 

to be shown how much time remains to accept a bid. 

Some embodiments of the invention allow the customer to change the sort 
order, e.g. sort by preferred source list. Additionally, if more complicated rates are 
being presented in a single bids 408 component, the sort order options may allow the 

30 user to quickly sort to the top the most favorable rate quotes for each category of rates 
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presented. In some embodiments, if coloring, or shading, is used, each quote is 
separately colored, or shaded, according to the rules. 

More complicated bids can also be presented using multiple bids 408 
components. For example, in a two-way bid request, where the user wants both 
5 buying and selling prices, two bids 408 components could be shown on the display 
400. 

Tasks List Details 

After execution, the tasks list 402 status for a task, e.g. the task 410, can be 
updated to reflect execution. This is desirable for ensuring that the tasks list 402 
10 shows the most relevant information to the customer in an easily accessible form. 

Accordingly, one or more of the use of colors, shading, icons, sorting and/or filtering 
of the display of the tasks list 402 can be used to reduce clutter and improve 
workflow. 

In some embodiments of the invention, executed tasks are shaded a different 
15 color from non-executed tasks, e.g. gray. Thus, upon execution, the task 410 would be 
shaded gray. This provides a quick visual indication that the task 410 has been 
executed. In some embodiments of the invention, additional shading colors are used to 
indicate whether or not counter party settlement information has been received, e.g. 
light gray for executed but awaiting settlement information and gray for executed and 
20 settlement information received. Still more shading variations can be used for 

different status conditions as well as different shades, e.g. customer selected colors. 
Colors and icons can be used to provide a similar effect to shading in some 
embodiments of the invention. 

In some embodiments of the invention, automatic sorting or filtering of the 
25 tasks list 402 can occur. In embodiments that use sorting, completed tasks are 

automatically sorted to the bottom of the tasks list 402. This keeps tasks that remain to 
be completed near the top. Thus, after the task 410 is executed, it would sort to the 
bottom of the list, and the task 412 would be at the top. In filtering embodiments, the 
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task 410 would no longer appear in the tasks list 402 unless the customer selected 
controls in the user interface to see all tasks, e.g. in a menu option or button control. 

Some embodiments of the invention use combinations of these approaches, 
e.g. shading and sorting. This allows the customer to quickly scroll the list and easily 
5 see completed tasks; however, at the same time the tasks at the top of the list will be 
those most important to the customer — the non-executed tasks. 

Additionally, the task information imported into the foreign exchange 
execution module 112 may include status information, e.g. important, execute 
tomorrow, etc. The specific status information can also be derived from one or more 

1 0 system, customer, and/or management, defined rules in the business logic 310. For 
example, embodiments of the invention may support rules to associate an icon with 
forward tasks and to sort them to below spot tasks. The rules can be adjusted by the 
management 100, and/or its customers. This allows the system to be flexibly 
programmed to meet business needs and stylistic preferences of individual companies 

15 and traders. 

The multi-bid process used by embodiments of the invention will now be 
described in greater detail. 

Multi-Bid Process Details 

Once the customer submits her/his request, a multi-bid execution process 
20 commences. The process is detailed in Figure 5 according to the principles of the 

Unified Modeling Language. The flow of time is from top to bottom and is shown by 
the arrow 500. The participants are the customer 502, the transaction center 504, and 
one or more dealers, represented by a single dealer 506. The participants 
communicate across the network 304, shown with dashed and dotted lines. 
25 The process starts after a customer completes her/his request in the request 

choices 406 component. She/he can click on a button, or other user interface element, 
to submit the request for bids at step 508. 

At the transaction center 504, the server side components of the foreign 
exchange execution module 1 12 reside. The transaction center 504 may be distributed 
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geographically across the globe among many computer systems. In this example, the 
transaction center 504 provides the elements 306-312 of Figure 3, e.g. the server side 
elements of the foreign exchange execution module 112, either entirely or across 
multiple, geographically distributed computer systems. 
5 According to the business rules implemented in the business logic 3 1 0, the 

request from the customer is distributed to all currently active dealers with whom an 
appropriate relationship exists. See the section "Third Party Surety," below, for more 
detail on appropriate relationships. The business rules are designed to ensure that the 
dealers that will receive quotes at step 512 meet one or more of the following 
10 requirements: (1) online and ready to trade, (2) trading in bid currency; (3) credit 
relationship with customer; (4) latency and QoS guarantees being met; and/or (5) 
follow supplied rules for customer and dealer, e.g. dealer is limited to USD Z in trades 
per day, etc. 

At step 5 12, the request is sent to all of the appropriate dealers and an X 
1 5 second limit begins to countdown. The X second limit defaults to thirty seconds in 
some embodiments of the invention. In other embodiments of the invention, longer 
periods of time are provided when dealers are asked to give more complicated quotes, 
e.g. packaged deals, different time horizons, etc.; see below for more details. 

Once placed, the bids are returned, e.g. the dealer 506 returns her/his bid at 
20 step 512. Dealers are not obligated to bid on any transaction, e.g. the dealers 506 need 
not act as market makers, though they may if they choose. The transaction center 504 
enforces the X second limit by aggregating only bids received in the time window at 
step 514 from all dealers. Where appropriate, a small latency tolerance may be added 
to the limit by the transaction center 504 to account for the current characteristics of 
25 the network; see below for more details. The X second limit and the tolerance, if any, 
can be implemented using one or more business rules in the business logic 310. For 
example, one embodiment might use a thirty second limit with a maximum 250 ms 
latency tolerance. Also, see below for further discussion of timing related issues on 
the network. 
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Once the bids are aggregated at step 514, they are reported en masse at step 
5 1 6 to the customer 502. At this point, little more than X seconds total has passed 
since the time the requests were broadcast at step 510. 

The customer 502 is given a Y second limit to select a bid. If she/he does not 
5 select a bid in that time period, she/he would have to re-bid the transaction at step 508 
to obtain the needed foreign exchange. Additionally, from the time when a dealer, e.g. 
the dealer 506, places a bid at step 512, up until the user selects a bid, at step 522, a 
dealer may pull her/his bid, e.g. step 518. If the pull request is made before the 
customer selects the bid, the pull will be effective and will also be transmitted to the 
10 customer 502 at step 520. 

In some embodiments, the Y second time limit defaults to five seconds. The 
amount may be adjusted up, or down, for more complex transactions. 

At step 522, when the customer 502 selects a bid, the banks are informed at 
step 524. Additionally, the bank may be requested to acknowledge completed trades, 
15 at step 526. Also, a confirmation can be sent by the transaction center 504 with 
counter-party settlement information at step 528. 

Advantages of Time Limits 

The X second and Y second time limits serve several purposes for both dealers 
and customers. They limit exchange risk for dealers, e.g. the dealer 506, because as 

20 noted, quotes may change as often as twenty times a minute. Thus, it is important 
dealers not commit to a price for an extended period. However, this has a beneficial 
effect for customers, e.g. the customer 502, as the dealers know the quote will have an 
extremely limited life and can make their best offer. 

The time limits also ensure fairness. Because all dealer offers are aggregated 

25 and presented to the user en masse, the customer, e.g. the customer 502, gets the full 
benefit of the multi-bid system and can evaluate all of the offers they receive. Also, 
dealers cannot gain an advantage based on their computer systems, e.g. better/closer 
network connection, over other dealers. 
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The specific time limits, and latency tolerances, can be adjusted. For example, 
if the thirty second default for the X second time period is considered too long a time 
to have offers outstanding, the amount can be scaled back. Similarly, some 
embodiments of the invention allow customers and dealers to enter certain more 
5 complicated trades, or request more complicated bids. The X second limit and the Y 
second limit can be adjusted in response to these trades. 

Lastly, on the latency front: Unlike dedicated connections, where the issue is 
one of physical connectivity, in packet-switched networks, there may always be some 
latency. The system can be adjusted to accommodate different latency characteristics. 
10 In some embodiments of the invention, the transaction center 504 is managed by an 
entity that contracts to provide at least portions of the carriage for the network 304. 
The entity controlling the transaction center 504 can adjust latency tolerances in 
accordance with the characteristics of the network 304 at any given time. 

In some embodiments, real time monitoring of packets reaching the 
15 transaction center 504 is used to measure the quality of service (QoS) and adjust 
latency tolerances up, or down, in accordance with the network's real time 
performance. In some embodiments, the adjustments are limited by a predetermined 
limit — a maximum latency budget — of for example, 250 ms. 

Time Limits 

20 Table 3 sets forth the time limits used by some embodiments of the invention 

for various purposes. The table is broken down along categories of currency with 
major currencies having generally shorter time limits than secondary and exotic 
currencies, e.g. less common currencies. Numbers in parenthesis indicate the default 
time according to some embodiments of the invention. 
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Action 


Major Curency 


Secondary 
Currency 


Exotic Currency 


Vs. USD or Natural Cross 


Basic X Second 
Limit (Spot) 


5 - 35 sec 
(25 sec) 


5 — 45 sec 
(35 sec) 


5-70 sec 
(60 sec) 


Outright 
Forward (Even 
Period) 


5-45 sec 
(40 sec) 


5 - 70 sec 
(60 sec) 


5-85 sec 
(75 sec) 


Outright 
Forward (Odd 
Period) 


5-60 sec 
(50 sec) 


5-80 sec 
(70 sec) 


5-95 sec 
(85 sec) 


Respond to Two- 
Way Bid 
Request 


Add 10 seconds 


Add 10 seconds 


Add 10 seconds 


Natural Cross 


Add 1 0 seconds 


Add 1 0 seconds 


Add 10 seconds 


Legacy 
Currencies 


Add 5 seconds 


Add 5 seconds 


Add 5 seconds 


Crosses 


Spot Cross 


5-45 sec 
(35 sec) 


5 — 55 sec 
(45 sec) 


5-70 sec 
(60 sec) 


Fwd Outright 
Cross (Even) 


5 - 55 sec 
(45 sec) 


5-70 sec 
(60 sec) 


5-90 sec 
(80 sec) 


Fwd Outright 
Cross (Odd) 


5-65 sec 
(55 sec) 


5-85 sec 
(75 sec) 


5 - 100 sec 
(90 sec) 


Swans 

Add 10 seconds for uneven swaps and forward forwards. 


Fwd Swap 
(Even) 


5-75 sec 
(65 sec) 


5-85 sec 
(75 sec) 


No preferred timing, 
e.g. over 1 00 sec. 


Fwd Swap (Odd) 


5-90 sec 
(80 sec) 


5-100 sec 
(89 sec) 


No preferred timing, 
e.g. over 100 sec. 


Fwd Swap Cross 
(Even) 


5 - 100 sec 
(90 sec) 


5- 100 sec 
(90 sec) 


No preferred timing, 
e.g. over 100 sec. 


Fwd Swap Cross 
(Odd) 


5 - 100 sec 
(90 sec) 


5 - 100 sec 
(90 sec) 


No preferred timing, 
e.g. over 100 sec. 


Additional Times 


Latency 
Tolerance 


100 -350 ms 
(250 ins) 


Basic Y Second 
Limit (Spot) 


3-10 sec 
(5 sec) 


Table 3 
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Embodiments of the invention may allow additional time to allow for bidding 
and accepting more complex transactions as described below. Additionally, the exact 
timings can be adjusted due to market conditions and the ability of participants to 
respond, for example as dealers become more accustomed to the system, the basic X 
5 second limit for a major currency might even be dropped below five seconds. 

. Anonymity: When is Counter-Party Information Known? 

In some embodiments of the invention, the identities of counter-parties to a 
transaction are concealed from the parties until a trade is accepted. In some 
embodiments, only customer identities are kept confidential, while dealer identities 

10 are provided with the bids sent to customers. 

In some embodiments, a customer — or dealer — can select whether to reveal 
her/his identity. For example, MegaBank might elect to reveal its identity despite the 
fact that counter-party information might normally be kept secret. This may be 
desirable for MegaBank if they believe it will improve the odds of their bid being 

1 5 selected. Similarly, a company could reveal its identity, again hoping that it may 
cause the dealers to quote better prices. 

Settlement Handling 

For confidentiality reasons, settlement information can be held until after a 
trade is completed. In some embodiments, the selection of a bid at step 522 includes 

20 transmission of the customer's settlement information for the trade. Similarly, in some 
embodiments, the dealer's acknowledgment of the trade at step 526 can include dealer 
settlement information for the trade. 

The automation of this process can significantly reduce the back office 
overhead — and the chance for errors — in foreign exchange transactions. In some 

25 embodiments, the transaction center 504 generates one or more error messages if a 
dealer, e.g. the dealer 506, does not provide settlement information by a 
predetermined period, e.g. 1700 hours local time, four hours after a trade, etc. Similar 
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errors can be generated for customers, e.g. the customer 522, if they did not provide 
sufficient settlement information. 

In some embodiments of the invention, the errors may cause electronic mail, 
facsimiles, pager notifications, telephone calls, and/or some other contact to be placed 
5 or sent to the respective dealer or customer for failing to provide settlement 

instructions. In some embodiments, an additional service fee may be assessed for 
failure to provide settlement instructions in a timely fashion, and/or for contacting the 
dealer, or customer. 

- The settlement information received from the counter-party can be paired with 
10 the task information and sent out as part of the one-click transaction reporting process 
of step 1 14. In some embodiments, if settlement information for a particular 
transaction has not been received when the process of step 1 14 is requested, the task is 
automatically held until the settlement information is available. It can then be 
transmitted immediately upon receipt without further user intervention, or with the 
1 5 next requested transmission of completed transaction information. 

Next, the user interface from the dealer perspective will be considered. 

Dealer User Interface 

Figure 6 illustrates a user interface provided to dealers, e.g. traders acting on 
behalf of banks or other institutions bidding to meet customer foreign exchange 

20 needs, according to one embodiment of the invention. This interface allows for rapid 
multi-bid execution. 

The graphical user interface can be provided by the display logic 300 in 
conjunction with the presentation logic 308 and the business logic 310. The interface 
is shown in Figure 6 with the display 600, e.g. a physical display or a region on a 

25 physical display such as a window, occupied with various interface components. 

There is one main component according to some embodiments of the invention: place 
bid areas 602A-B. Each place bid area (e.g. the place bid areas 602A-B) could be 
displayed as separate windows or as part of a larger single window. In some 
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embodiments, the position of the user interface elements can be changed and, where 
appropriate, saved for use in later sessions. 

Several other interface components may be present on the display 600; these 
include menus; button bars; pricing information, e.g. from a data feed to show quotes 
5 being offered elsewhere; reporting options; and/or other content. For example, the 
dealer might select a button in a button bar to produce a report showing executed 
trades and confirmation information. Another button might allow the dealer to 
download trade and settlement information to her/his back office systems. 

The basic interface provided affords several place bids components allowing a 
1 0 dealer to respond to multiple bid requests simultaneously. The number of place bid 
components is limited by the display space available, the capacity of the dealer to 
handle multiple requests, as well as the policies of the dealer's management, e.g. the 
bank. 

Each place bid area, e.g. the place bid area 602A, affords a timer, e.g. the 
15 timer 604 A, as well as display of the request wanted and a data entry area to provide a 
rate quote. In some embodiments of the invention, the dealer's most recent quote for a 
currency is shown together with the aging history of that quote, e.g. "Your previous 
quote: 1.4005 (60 seconds ago)". In some embodiments, the bid entry area is pre- 
filled with the most recent quote. In other embodiments, shown in Figure 6, the bid 
20 entry area is pre-filled with all but the last digit of the previous quote. 

This can be further generalized based on the volatility of a particular currency. 
For a quote of "1 .2345", the "L23" is the handle, the "0.004" is the big figure and the 
"0.0005" is the little figure, or tick. A pip is the smallest amount the tick can move by 
and may be set by convention: In some instances, moves by half-pips are supported as 
25 well. 

Thus, for example, some embodiments of the invention pre-enter the handle, 
but leave the big figure and little figure for the dealer to enter. Others, include the 
handle and big figure, but leave the litde figure for the dealer to enter. 

Still other systems support the use of graphical and/or keyboard approaches to 
30 adjusting the quote quickly. For example, the "+" and "-" keys as well as up and down 
arrow buttons on the screen could be used to easily adjust the little figure up or down 
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by a pip. Other controls might cause the big figure to move, e.g. shift key plus +/- or a 
mouse click on the arrow buttons. Still others might cause half-pip movements, e.g. 
option key plus +/- or a mouse click on the arrow buttons. 

The particular interface for quote entry is thus highly customizable to the 
5 needs of a particular dealer and/or her/his business. For example, the capability for 
half-pip movement might only be enabled at businesses that provide quotes on the 
half-pip. 

A submit button, e.g. the submit button 606, is provided to allow the user to 
submit a quote. In some embodiments, if the dealer presses the return key, or other 

1 0 similar key, in the bid entry area, the quote is automatically submitted. The timer 
604A shows a countdown of the time remaining to submit a bid. Additional user 
interface features may allow dealers to selectively reveal, or conceal, their identities 
on a per quote basis. 

In many instances, dealers may desire to wait until close to the end of the 

1 5 period afforded before placing and submitting their bid. In these instances, the dealer 
may enter her/his quote at the start of the time period, but delay submission until, for 
example, two seconds remain. This allows the dealer to further minimize their 
exchange risks. 

Additionally, business rules may be defined to inform the dealer 506 when a 
20 quote she/he is entering deviates more than a predetermined amount from the most 
recent quote she/he entered. The amount can either be defined in absolute terms, e.g. 
± 0.0010, or in percentage terms, e.g. ± 3%. In some embodiments of the invention, 
there is a system supplied value that can be further adjusted by the dealer. In cases 
where the entered quote deviates more than the predetermined amount, after the 
25 dealer hits the submit button 606, she/he can be asked to confirm her/his entry. 

After submitting a bid, the display might look like the bottom half of Figure 6 
as shown in the place bid 602B component where a placed bid is shown together with 
a button 608 to allow the dealer to pull her/his bid; a keyboard shortcut may also be 
provided. The timer 604B can display the amount of time the customer has remaining 
30 to accept the bid. If the customer accepts the bid, the display can change again to 
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reflect that and request confirmation — and settlement information, if not already 
provided. 

In some embodiments, a keyboard shortcut is assigned to each of the place bid 
components, e.g. A, B, C, etc. Pressing that keyboard shortcut shifts the cursor focus 
5 to the corresponding enter bid area. 

The system can place new requests for bids in open place bid components, e.g. 
ones not currently occupied by other requests/offers. In some embodiments, a signal is 
provided if there are insufficient open place bid components. In other embodiments, a 
new place bid component is opened so as not to overlap the others on the display 600. 
1 0 In some embodiments, the dealer can dynamically select the currencies she/he 

is currently trading in from a pull down menu or dialog activated on the display 600. 

In some embodiments, the dealer can generate a variety of reports for her/his 
management, e.g. the bank. 

In some embodiments, the place bids components and the customer 
15 components of Figure 4 can be displayed simultaneously to support customers to act 
as dealers and vice versa. For example, a large multinational company might wish to 
allow its customers serve as dealer to meet its foreign exchange needs. In these 
embodiments, the customer could define filters to further limit which bids are 
presented to it, e.g. according to the tasks on the customer's tasks list 402. 
20 As noted, embodiments of the invention can support customers acting as 

dealers and vice versa, e.g. for inter-corporate trading. Accordingly, when 
appropriate, a single display, e.g. the display 400, might include a place bid area, e.g. 
the place bid area 602 A. 

Next, the network and back-end environment supporting embodiments of the 
25 invention will be discussed in greater detail. 

D. Network and Back End Environment 

Some embodiments of the invention are designed to interoperate with public 
packet-switched networks, e.g. the Internet However, the time sensitivity of the 
information, as well as security concerns, should be accounted for. 
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A secure transport protocol such as TLS version 1.0, can be used for 
communications across the network. The TLS protocol was . formerly known as secure 
sockets layer (SSL) protocol. The TLS protocol is further defined by the Internet 
Engineering Task Force, Request For Comment number 2246, January 1999. The 

5 TLS protocol, however, is limited to providing encryption (privacy), party 
identification (authentication with digital certificates), and message tampering 
detection (reliability) at the transport layer. 

Additionally, one or more of a user password, a digital certificate, and/or a 
physical security token can be used to authenticate users within the foreign exchange 

10 execution module 112, e.g. at the application layer. For example, in one embodiment 
of the invention, users have a password and a SecurelD(TM) card. Thus, neither the 
password nor the SecureID(TM) card, without the other, would allow someone access 
to the foreign exchange execution module 1 12. 

In order to provide the foreign exchange execution module 1 12 in a 

1 5 client-server configuration across non-dedicated connections, there are additional 

issues that arise, e.g. managing latency, verifying packet times, etc. For example, if a 
client, e.g. a customer's computer, could forge the packet times, the customer might 
be able, to gain some advantage. These effects can be minimized by enforcing the time 
limits on the server, e.g. at the transaction center 504 in the multi-bid execution 

20 process shown in Figure 5. 

However, measuring and managing latency remains important. Embodiments 
of the invention may make use of specific network configurations and topologies to 
reduce the effects of latency. For example, embodiments of the invention may 
position equipment in areas with major use to allow traffic to be quickly routed to 

25 guaranteed QoS network connections, e.g. by establishing points of presence. For 
example, there might be points of presence in New York, Tokyo, Hong Kong, 
Singapore, London, Frankfurt, and San Francisco with guaranteed QoS connections to 
one another and/or the transaction center. This configuration provides reduced costs, 
e.g. no need for end-to-end QoS connection and increases the range of equipment 

30 usable for client terminals, e.g. wireless computers, dial-up connections, public 
Internet kiosks, is increased. Hot potato, or cold potato, routing approaches can be 
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used to cause the data to leave the "public" segments of the Internet for the points of 
presence as rapidly as possible. Hot potato routing, also known as closest exit routing, 
is a type of routing that moves traffic out of a particular network as quickly as 
possible. Cold potato routing, also known as furthest exit routing, is a type of routing 
5 that keeps traffic within a particular exit for the longest possible period. Both 

approaches may be desirable depending on whether or not traffic is symmetrically 
routed. 

Further, this approach has applicability outside the Internet, but more 
generally for any type of packet-switched network over which embodiments of the 
10 invention may operate. This is because this approach helps minimize the high cost 
associated with having a large number of guaranteed QoS links. Thus, for example, a 
private — or virtual private — packet-switched network without guaranteed QoS could 
be used in conjunction with a relatively small number of QoS links between selected 
points of presence. 

1 5 The time-sensitive nature of the data makes it desirable to measure latency — 

and the variance in the latencies — to ensure that customers and dealers are receiving 
information in a timely fashion. The foreign exchange execution module 112 can then 
respond to the detected latencies by one or more of: 

(1) notifying the customer/dealer and allowing them to choose how to 
20 proceed; 

(2) enforcing a maximum latency policy, e.g. cut off use if measured latency 
exceeds maximum; 

(3) attempting to re-route packets to avoid latency, either at the network or 
application layers; 

25 (4) adjusting the latency tolerance of the system on a per transaction basis 

according to the latencies for the participants; and/or 
(5) other approaches. 

Latency can be measured both at the application layer, e.g. Open Systems 
Interconnect (OSI) layer 7, and at lower layers, e.g. OSI layers 1-6. For example, 
30 some embodiments of the invention may make use of timestamps appended by 

network devices that support the Internet Protocol (IP) timestamp option to measure 
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latency, and its variance. Similarly, some embodiments may implement packet re- 
routing at the application layer, e.g. OSI layer 7, e.g. with the business logic 310 
instructing network devices to re-route packets if it is determined that the QoS terms 
are not being met. Alternatively, the re-routing can be done from application layer on 
5 the sever to the application layer on the customer or dealer computer, e.g. by 

providing a different IP address/machine for the client to connect to. For example, if 
client X is currently connecting via a proxy in New York, the connection could be 
re-routed by providing the client with the address of another server, e.g. in San 
Francisco, that will have better latency characteristics. 

10 Latency variance is also important because if the latency is 1 50 ms, but the 

variance is 100 ms, e.g. some packets are taking as much as 250 ms, that may exceed 
the latency tolerances — or the maximum latency — allowed. Accordingly, it may be 
appropriate to handle the situation as described above for high latency connections. 

Additionally, embodiments of the invention may support application level load 

15 balancing, e.g. OSI layer 7. Unlike most load balancing approaches currently 

available which operate at lower layers, e.g. OSI layers 1-6, this approach involves 
analyzing load within the application and then sending one or more messages to 
network devices to re-route the traffic for load balance. 

An example may be helpful in understanding the distinction. For example, it is 

20 possible to use a Cisco(TM) Global Director from Cisco Systems, Inc., San Jose, 
California, to provide OSI layer 2-3 load balancing across servers. However, at 
present, this product is focused on balancing traffic and providing redundancy. There 
are some limited features for feedback from servers. 

In contrast, embodiments of the invention primarily use application level, e.g. 

25 OSI layer 7, criteria to balance traffic. Accordingly, the application level is directing 
network traffic, e.g. to avoid latency and to ensure processing resource availability. 
This approach may, when appropriate, be synergistically combined with products 
such as the Global Director. 

The combination of transport layer security, e.g. via the TLS protocol, and 

30 network configurations that are responsive of the time-sensitive nature of the data can 
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be used to implement embodiments of the invention over a variety of packet-switched 
networks at low cost, while ensuring high reliability and strong security. 

E. Example Use 

It may be helpful to explore how three companies might make use of the 
5 foreign exchange execution module 1 12 as well as the overall workflow automation 
process. In this example, only CreditCardCo, the fictional credit card company, will 
be considered. 

CreditCardCo has the process 202 performed for transactions in its transaction 
processing system according to the business rules for when foreign exchange is 
1 0 needed. This results in the automatic identification of foreign exchange needs from 
credit card holders' transactions. This information is automatically aggregated for 
CreditCardCo, and is transmitted automatically to the foreign exchange execution 
module 1 12 at 0855 EST each morning for use by CreditCardCo's traders. 

If needed, CreditCardCo can have rules established to divide the trading 
15 among its traders, e.g. by currency. There is no need for an employee to record quotes 
received over the phone to provide comparisons. Instead, each trader acting for 
CreditCardCo sees her/his tasks list when she/he start trading in the morning. The 
traders can then complete the tasks with competitive execution through the multi-bid 
execution process. 

20 Now, with the same four traders, CreditCardCo can get more bids — and, 

hopefully, more competitive rates — for each foreign exchange transaction. That is 
because each trader's request will reach suitable counter-parties, e.g. from among the 
banks CreditCardCo convinced to sign up as dealers. For example, CreditCardCo may 
have convinced twenty-three of its banks to use the system as dealers. 

25 Traders press a single button on their user interface to transmit settlement 

information when they end their trading day. This causes the settlement information 
for counter-parties, as well as transaction details, to be transmitted from the foreign 
exchange execution module 1 12 to CreditCardCo's settlement systems. 
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Additionally, the foreign exchange execution module 1 12 provides reports to 
the traders' managers to allow them to assess whether the traders are selecting 
competitive bids. 

The overall experience of using embodiments of the invention is similar for 
5 companies such as WidgetCo and InvestCo. Additionally, embodiments of the 
invention can be integrated with enterprise resource planning (ERP) systems for 
integration with transaction information and other enterprise. Companies find a 
significantly more level playing field, e.g. in terms of access to competitive rates. 
Similarly, banks find that they have greater access to company's full transaction load. 
10 The implementation in a client-server architecture across packet-switched networks 
increases the level of access while permitting broad integration with other company 
systems. 

A number of ancillary costs for the companies — and banks — are also reduced. 
For example, companies can now identify their foreign exchange needs systematically 

1 5 and automatically. Further, the automatic association of settlement information with 
those needs reduces processing costs. Similarly, management costs are reduced as 
well since well defined metrics can be used to evaluate the performance of traders 
acting on the company's behalf. 

The availability of quality metrics may also make it viable for companies with 

20 relatively small foreign exchange needs to farm out the execution to a third party to 
act as the customer on their behalf. For example, now a third party executing trades 
for the management 100 can be evaluated quantitatively by the management. Also, in 
some embodiments, the foreign exchange execution module 112 will aggregate 
foreign exchange needs from multiple companies. 

25 Next, some additional features offered by various embodiments of the 

invention will be considered. 

F. Bidding for the Same Transaction with Different Time Horizons 



In many instances, the perception of exchange risk on behalf of dealers may be 
such that they wish to provide multiple bids and/or timed expirations for their bids. In 
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this configuration, each bid can have an associated time to live (TTL) that may be 
independent of the basic Y second limit for the customer to respond to bids. 

It is important not to confuse the concept of bids with different time horizons 
with forward foreign exchange transactions, e.g. requesting a quote for a transaction 
5 N days hence, which is supported by the foreign exchange execution module 1 12. 
Instead, this is dealers setting the TTL for an offered price quote. 

In these embodiments, the dealer may have options to set a TTL in seconds for 
each quote and enter multiple quotes via the dealer user interface. For example, the 
dealer could bid 0.9905 with a TTL of 3 seconds and 0.9910 with a TTL of 10 
10 seconds. If the Y second limit for customers to respond to bids is 10 seconds, both 
quotes could be presented to the customer and sorted separately. As appropriate 
quotes could become greyed out, or removed from the customer's list, as their TTL 
expires. 

Also, the process flow of Figure 5 can be extended to allow dealers to pull 
15 individual quotes (e.g. I want to pull my 10 second quote). Suitable adaptations can be 
made to the user interface of Figure 6 to support a selective pull functionality as well 
as entry of multiple quotes. 

G. Third Party Surety 

Foreign exchange transactions are high risk. In fact, a tremendous amount of 
20 money can easily be lost in minutes. For this reason, embodiments of the invention 
have business rules implemented in the foreign exchange execution module 1 12 to 
present requests for bids to only those dealers with whom a given customer has a 
credit relation — and sufficient outstanding credit. 

However, this limitation can actually be detrimental to both customers and 
25 dealers. From the customer perspective, her/his ability to receive the best quotes is 
limited by the number of institutions, and hence dealers, that can bid for her/his 
foreign exchange needs. Similarly, dealers make money by completing transactions; 
therefore, dealers would benefit from being able to bid on a larger number of requests. 
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Accordingly, some embodiments of the invention support third party surety. 
This third party may be a selected outsider, e.g. a Lloyd's of London, an insurer, etc., 
who acts as a third party credit guarantor, or may be another system participant, e.g. a 
web of trust model. Customer participants and dealer participants can then gain 
5 greater access by forming credit relationships with appropriate third parties. 

When third party surety is used in connection with the foreign exchange 
execution module 112, customer bids will be presented to dealers according to both 
the customer to dealer credit relations and third party surety credit relations. 
Additionally, an appropriate user interface can be provided to third parties providing 
1 0 surety to inform the foreign exchange execution module 1 1 2 of credit relationships, 
monitor credit available, and/or perform other tasks relating to providing surety 
services. 

When appropriate, the third party may receive a fee from the customer, the 
dealer, or both, for its role in the transaction. This can be automatically deducted by 
15 the foreign exchange execution module 112. Additionally, the third parties may 
charge other fees, e.g. credit line fees, require deposits, etc., to obtain their 
participation. 

Additional modifications to the customer and dealer user interfaces may be 
appropriate. For example, when displaying bids in the bids 408 component, an icon, 

20 or other visual indication, may be used to notify the customer that a third party surety 
relationship was used to obtain the transaction. This may also serve as a signal to the 
customer that an additional transaction fee may apply. When known, additional 
transaction fees from third parties can be included in cost differentials shown to the 
customer. Thus, two quotes for 1.4005 on a transaction may be different in the sense 

25 that one will cost an additional amount due to the use of one or more third party 
insurers. 

More generally, insurance reduces settlement risk and accordingly move the 
transaction model from a one-to-many based on credit relations to many-to-many 
based on participation in the market. 
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H. Package Trades 

Another variant form of multi-bid foreign exchange execution supported by 
embodiments of the invention is the packaged trade. This is useful if customers want 
to try to obtain a lower overall costs by bundling two or more foreign exchange needs, 
5 e.g. tasks, into a single request for bid. 

For example, a customer could bundle four small transactions, e.g. whose 
USD equivalent value is approximately USD 1,000,000 each, into a single request. 
This may make it more desirable to dealers to place competitive bids so as to receive 
the overall deal flow, e.g. USD 4,000,000, whereas taken individually the quotes 
1 0 might have been less competitive. 

Accordingly, some embodiments of the invention allow a customer to select 
multiple tasks from the tasks list 402 for packaged execution. The task detail 404 
component can show the information for the selected tasks. The request choices 406 
component can allow further input before requesting bids. 
1 5 From the dealer side, the user interface will allow her/him to easily enter 

multiple quotes in the place bid 602 A component. In some embodiments of the 
invention, the X second limit is extended beyond the system default for packaged 
trades, e.g. 40 seconds instead of a 30 second default. 

Back on the customer side, when bids are received, they can be shown as an 
20 indented table ranked by net cost for the packaged quote as a whole. In some 

embodiments of the invention, the packaged quote is shown as a series of line items 
with disclosure icons to allow expansion of the detailed quotes and costs of each 
transaction within the package. Given the additional information to be evaluated, 
some embodiments of the invention extend the Y second limit beyond the system 
25 default, e.g. 10 seconds instead of a 5 second default. 

I. Pricing Model 

The specific pricing model used by the provider of the foreign exchange 
execution module 1 12 can vary greatly. For example, licensing fees for software and 
support may be assessed against customers and dealers. However, this approach may 
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be sub-optimal for the provider, e.g. if the provider can make more money by giving 
away the needed client side software while charging for transaction execution. 

One embodiment of the invention charges usage fees to customers and dealers. 
For customers, these embodiments of the invention charge a modest usage fee relative 
5 to the size of the trade in millions of dollars. This is because the savings for larger 
trades, e.g. the spread between buy and sell quotes, tends to drop as volume increases 
in the foreign exchange market. (Note, however, that studies have observed a point of 
inflection where the spread goes back up at a certain point, e.g. for ultra-large 
transactions.) 

10 Therefore, assessing customers based on the trade size fairly charges them for 

the increased value they receive for larger transactions — smaller spreads. For 
example, some embodiments of the invention charge between USD 5 and USD 50 per 
million dollars involved in the transaction. 

In contrast, banks, e.g. dealers, are attempting to generate revenue. Their 

1 5 revenue is dependent on the product of the volume and the spread. Accordingly, 
dealers benefit the most from larger spreads. However, given the spread/volume 
relation described above, the result for dealers is that revenue is somewhat flat at first 
and then, as volume increases, revenue trends upwards slowly because the spread is 
decreasing. 

20 Accordingly, some embodiments of the invention charge a small flat fee, e.g. 

USD 5-100 per transaction. For example, a flat fee of USD 20 for each executed trade 
could be assessed. Since this is a flat fee for execution services, it is not tied to the 
trade and will not discourage dealers from participating in larger transactions where 
they can make the most revenue. 

25 However, a variety of other pricing models may also be usable. For example, 

customers could be charged a flat fee plus a volume related commission. Similarly, 
dealers could be assessed a flat monthly cost on a per seat basis, e.g. USD 1 ,000 per 
month per seat, as opposed to per transaction charges to encourage dealer 
participation. 
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J. Rules Based Bid Selection 

Some embodiments of the invention may allow customers (e.g. the customer 
502) to define one or more rules for automatically selecting from among received 
bids. The rules can be defined using a variety of approaches, e.g. expert system, small 
5 programmatic logic statements, visual programming, selection from system provided 
rules, and/or other approaches. 

This may simplify the execution process for customers by removing the need 
to make a decision in the Y second time limit provided by the multi-bid execution 
process of Figure 5 . 

10 A simple rule that a customer might define is: "Take the bid from MegaBank 

if its cost is within 3% of the best bid, otherwise take the lowest cost bid." This rule 
defines a preference for using MegaBank over other banks, but only when 
MegaBank' s quote is sufficiently low in cost as to be comparable to the lowest cost 
bid. 

15 It is not necessary for all rules to select a price. For example, the rule "Sort 

quotes from MegaBank to the top of the list and flag with red icon if outside 3% of 
lowest cost bid," simply helps implement a management's policy of considering 
MegaBank' s bids first. However, the customer's decision process is still improved 
since she/he has requested that the quote be flagged if it is not a very good quote, e.g. 

20 3% from lowest cost quote here. However, with this rule, the customer (e.g. the 
customer 502) retains the final decision as to which quote to accept. 

K. Price Discovery 

The multi-bid execution process can also be viewed as a form of price 
discovery. This can be contrasted to the price discovery, or matching, of orders at the 
25 New York Stock Exchange, or other similar exchanges. However, it serves a similar 
purpose by allowing customers and dealers to match 
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L. Limit Orders 

Some embodiments of the invention may allow customers to place limit 
orders. This may serve to filter incoming quotes and/or allow customers to automate 
foreign exchange execution. 
5 For example, a customer CI could review several tasks for the day and for 

one, e.g. BUY EUR 50,000, spot, select automatic execution with a limit price of 
0.9950. The system could monitor various market data about the price, e.g. from 
public data feeds and/or quotes being given to other customers, and send out a bid for 
this foreign exchange need at a suitable time. Further, the system could automatically 
1 0 select the best bid under the limit price. 

Alternatively, embodiments of the invention could prompt the user to select 
bids when they are received — pre-filtering bids over the limit bid. In this 
configuration, the system could select the appropriate time to bid the task, and then 
present the resulting price quotes to the customer. 
1 5 This allows customers with a large number of tasks to devote their time to 

price sensitive transactions, while knowing that other tasks are being executed in 
accordance with their general instructions, e.g. a ceiling on rates. 

Appropriate colors, shading, and/or icons can be used in the tasks list 402 to 
signify tasks being handled in an automated, or semi-automated, fashion. For 
20 example, a computer icon might be placed to the right of a task description to indicate 
it is being handled by the foreign exchange execution module 1 12. In some 
embodiments of the invention, it is not possible for dealers to ascertain whether or not 
a transaction is being requested for automated bidding as opposed to a "live" 
customer. Further, the task could be automatically removed from the tasks list 402, 
25 when completed; see above for more discussion of the tasks list user interface. 

In some embodiments, limit orders and automated execution can support rules 
based bid selection. For example, in addition to specifying a limit price, a customer 
could supply one or more rules to apply in selecting bids. 

Additionally, although rules based bid selection and limit orders have been 
30 described primarily from the customer perspective, similar approaches can be 
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employed by dealers. For example, embodiments of the invention might permit 
dealers to establish rules for transactions (e.g. "If total transaction size is less than 
USD 1,000,000, use most recent price quote if quote is less than 60 seconds old"). 
Similarly, dealers could request special treatment for certain conditions (e.g. "If 
5 customer is from my preferred customer list, flag with star icon'*). Such a rule would 
help give the dealer a better visual indication of when its preferred customers — from a 
list it has established — are requesting bids. 

M. E-Commerce Interface 

Embodiments of the invention can be configured to interoperate with 
10 electronic commerce, or e-commerce, sites. Two embodiments of the invention 
incorporating this will be considered, a transaction service variant and a real-time 
pricing variant. The two may both be used simultaneously, if appropriate. 

Transaction Service Variant 

For example, a site such as Business2Business.com, a fictional business to 
1 5 business transaction site, could, upon completion of a transaction between business 
Bl and business B2: 

(1) identify needed foreign exchange for a party, e.g. Bl 

(2) offer to provide the party foreign exchange execution, e.g. present a web 
page with a button for "Fulfill my foreign exchange needs now/' 

20 (3) act as an intermediary for the ultimate customer, Bl , in the foreign 

exchange execution module 1 12 by placing the foreign exchange need for. 
bid. 

(4) Present received price quotes from dealers to Bl 

(5) and responsive to acceptance of a price quote by Bl, signaling acceptance 
25 to the dealer who submitted that price. 

In some embodiments of the invention, this service is charged for separately by the 
provider from any service charges, fees, and commissions that are charged for using 
the foreign exchange execution module 112. 
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The savings in time — and money — for businesses using this service, e.g. Bl, 
can be considerable. Because it serves to remove exchange rate risk from the 
transaction by allowing the risk to be limited almost immediately upon completion of 
the transaction. 

5 Real-time Pricing Variant 

Other embodiments of the invention use a similar approach but provide real- 
time price quotes. For example, a site such as Business2Business.com, a fictional 
business to business transaction site, could automatically request price quotes in, for 
example, Euros, for European based customers using the multi-bid process described 

1 0 above. A more detailed example may be helpful. 

Assume business Bl and business B2 are conducting a transaction over 
Business2Business.com, and that business Bl works in United States Dollars, but 
business B2 works in Euros. Embodiments of the invention can allow 
Business2Business.com to automatically request price quotes in the correct currency 

1 5 and allow the two businesses to eliminate exchange risk. 

As a result, when B2 reviews Bl's proposal as stored at 
Business2Business.com, a request for bids can go out, and the price shown to B2 will 
be in Euros based on the best price quote received. Business B2 then has the 
capability to accept the offer at that exchange rate and limit its currency exposure. 

20 The Y second time limit typically used in the multi-bid execution process might be 
lengthened to allow B2 a slightly longer decision period. If desired, as quotes time 
out, new bids can be solicited. 

Some embodiments of the invention automatically identify the date when 
payment is expected, e.g. the date the foreign exchange is needed, so that the request 

25 for bids is sent out as an appropriate forward request. As appropriate, this 

identification can be assisted by the commerce vendor, e.g. Business2Business.com in 
this example. 

Some embodiments of the invention, show both the foreign currency amount 
and the best bid, e.g. "USD 1 ,000,000 [Best Bid Now EUR 1 ,005,000]", etc. 
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Some embodiments of the invention use automatically obtained quotes as 
described more fully below to provide pricing. 

N. Automatic Quoting 

For a number of reasons, it may be desirable for dealers to set up automatic 
5 quotes to handle certain transactions, e.g. under a certain amount in USD. For such 
transactions, the dealer can maintain a table using the dealer interface of quotes for 
various transactions together with spreads for different classes of customers, e.g. 
based on their credit worthiness with the dealer. The customer can still benefit from 
the multi-bid process because that quote may go up against quotes from live dealers or 
1 0 from dealers who have narrower adjustments and more frequently updated tables. 

Some embodiments of the invention do not indicate to customers whether or 
not a quote is from a "live" dealer or is an automated quote of some sort. Still more 
sophisticated automatic quoting mechanisms can be integrated, e.g. through the use of 
client side scripting, hosted pricing agents for dealers, and/or an application 
1 5 programmers' interface (API) for coupling a dealers' pricing agent with the system. 

O. Conclusion 

Combinations of the individual features described above can also be used by 
embodiments of the invention. The foregoing description of various embodiments of 
the invention has been presented for purposes of illustration and description. It is not 
20 intended to limit the invention to the precise forms disclosed. Many modifications and 
equivalent arrangements will be apparent. 
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CLAIMS 

What is claimed is: 

1 . A foreign exchange computer system comprising: 

a number of dealer computers, the number of dealer computers for responding 
5 to requests for bids on foreign exchange from customers with price quotes; 

a number of customer computers, the number of customer computers for 
placing requests for bids on foreign exchange and responding to received 
price quotes; 

a network coupling the dealer computers to the customer computers; and 
10 a transaction server for enforcing time limits associated with a multi-bid 

foreign exchange execution and monitoring latency over the network. 

2. The foreign exchange computer system of claim . 1 , wherein at least two dealer 
computers corresponding to two different legal entities and at least two customer 
computers corresponding to two different legal entities. 

15 3 . The foreign exchange computer system of claim 1 , wherein the network 

includes a number of network devices, and the transaction server, responsive to the 
monitoring latency, sending an instruction to at least one of the number of network 
devices to reroute communication among the number of dealer computers and the 
number of customer computers. 

20 4. The foreign exchange computer system of claim 3, wherein the monitoring 
occurs at layer 7 and the instruction modifying behavior of the at least one of the 
number of network devices at layers 2 through 6. 
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5. The foreign exchange computer system of claim 1 , wherein the network is the 
Internet and wherein the number of dealer computers and the number of customer 
computers communicate using Internet connections. 

6. The foreign exchange computer system of claim 1, wherein the network is a 
5 packet-switched network, and the number of dealer computers and the number of 

customer computers communicate using a transport layer encryption. 

7. The foreign exchange computer system of claim 6, the transport layer 
encryption comprises a transport layer security (TLS) protocol. 



10 



8. The foreign exchange computer system of claim 1, wherein the network 
supports both guaranteed quality of service (QoS) and non-guaranteed QoS 
connections between the number of dealer computers and the number of customer 
computers. 

9. The foreign exchange computer system of claim 8, further comprising a 
number of points of presence, each of the number points of presence coupled to the 

1 5 transaction server over the network via guaranteed quality of service connections, and 
the number of dealer computers and the number of customer computers coupled to 
respective points of presence with non-guaranteed QoS connections. 

1 0. The foreign exchange computer system of claim 1 , wherein the enforcing time 
limits associated with multi-bid execution comprises: 

20 selecting a first time limit from 3-1 00 seconds for dealer computers to respond 

to requests for bids on foreign exchange from customers and 
rejecting price quotes from dealer computers received after the first time limit. 

1 1 . The foreign exchange computer system of claim 1 0, wherein an average 
latency is determined for the network through the monitoring, and wherein the 

25 rejecting further comprises accepting messages received within the first time limit 
plus the average latency. 
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1 2. The foreign exchange computer system of claim 1 , wherein the enforcing time 
limits associated with multi-bid execution comprises: 

selecting a second time limit from 3-10 seconds for customer computers to 
respond to received price quotes and 
5 rejecting responses from customer computers received after the second time 

limit. 

13. The foreign exchange computer system of claim 1, wherein at least one of the 
number of customer computers comprises a handheld computer with a wireless 
connection to the network. 

10 14. The foreign exchange computer system of claim 1 , wherein at least one of the 
number of customer computers supports automated response to price quotes according 
to one or more rules. 

1 5 . The foreign exchange computer system of claim 1 4, wherein the one or more 
rules comprise at least one of a rule to select the best price quote, a rule to select a 

1 5 price quote from a preferred dealer if the price quote is within a predetermined range 
of the best price quote, and one or more rules defined by a customer. 

1 6. The foreign exchange computer system of claim 1 , wherein at least one of the 
number of dealer computers supports automated response to requests for bids 
according to one or more rules. 

20 17. The foreign exchange computer system of claim 16, wherein the one or more 
rules comprise an adjustment of a quote retrieved from a predetermined source based 
on creditworthiness of corresponding customers. 

18. The foreign exchange computer system of claim 1, wherein the transaction 
server generating customer execution information describing the dollar cost of 
25 customer computer executions compared to best price quote received for transaction. 
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19. The foreign exchange computer system of claim 1 , wherein the transaction 
server generating customer execution information describing the dollar cost of 
customer computer executions compared to a market comparable rate. 

20. The foreign exchange computer system of claim 1, wherein the transaction 

5 server supporting real-time monitoring of customer execution information for one or 
more of the number of customer computers corresponding to a single legal entity. 

2 1 . The foreign exchange computer system of claim 1 , wherein the transaction 
server supports automatic transfer of settlement information from customer computers 
to dealer computers responsive to customer computers responding to price quotes 

1 0 from dealer computers. 

22. The foreign exchange computer system of claim 1 , wherein the transaction 
server supports automatic transfer of settlement information from dealer computers to 
customer computers responsive to customer computers responding to price quotes 
from dealer computers. 

15 23 . The foreign exchange computer system of claim 1 , wherein at least on the 
customer computers comprises a dealer computer. 

24. The foreign exchange computer system of claim 1 , wherein the transaction 
server supports multi-bid execution of one or more of: outright forward transactions, 
spot transactions, spot-next transactions, tom-next transactions, spot-a-week 

20 transactions, spot-two-weeks transactions, spot-forward transactions; odd-date 
transactions, forward-forward transactions, long date transactions, currency swap 
contracts, and limit orders. 

25. A method of supporting foreign exchange using a first computer system 
coupled to a network, the method comprising: 

25 receiving a first message from a customer computer on the first computer 

system over the network, the first message corresponding to a request for a 
bid on foreign exchange from a customer; 
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identifying a plurality of computers to receive the request over the network 
using the computer system, the plurality of computers corresponding to 
dealers, each corresponding dealer having a relationship with the 
customer;. 

5 performing a multi-bid foreign exchange execution process for the request 

between the customer computer and the plurality of computers over the 
network using the first computer system, the first computer system 
enforcing time limits associated with the multi-bid foreign exchange 
execution and monitoring latency over the network. 

1 0 26. The method of claim 25, wherein the relationship with the customer comprises 
a credit relationship between the dealer and the customer. 

27. The method of claim 25, wherein the relationship with the customer comprises 
a third party that will insure settlement risk for the dealer with the customer. 

28. The method of claim 25, wherein the network supports both guaranteed 
15 quality of service (QoS) and non-guaranteed QoS connections between the first 

computer system, the customer computer, and the plurality of computers. 

29. The method of claim 28, wherein at least a portion of the network comprises 
the Internet. 

30. The method of claim 25, wherein at least two of the plurality of computers 
20 corresponding to different legal entities. 

3 1 . The method of claim 25, wherein the first computer system uses a transport 
layer encryption over the network to communicate with the customer computer and 
the plurality of computers. 

32. The method of claim 3 1 , wherein the transport layer encryption comprises a 
25 transport layer security (TLS) protocol. 
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33. An apparatus for supporting foreign exchange over a network, the apparatus 
comprising: 

means for receiving a first message from a customer computer on the first 
computer system over the network, the first message corresponding to a 
5 request for a bid on foreign exchange from a customer; 

means for identifying a plurality of computers to receive the request over the 
network using the computer system, the plurality of computers 
corresponding to dealers, each corresponding dealer having a relationship 
with the customer, 

1 0 means for performing a multi-bid foreign exchange execution process for the 

request between the customer computer and the plurality of computers 
over the network using the first computer system, the first computer 
system enforcing time limits associated with the multi-bid foreign 
exchange execution and monitoring latency over the network. 

15 34. The apparatus of claim 3 3 , wherein the customer computer in communication 
with the apparatus over a first network connection having a first latency, and the 
means for performing further comprises means for responding to the monitoring 
latency by sending a second message to the customer computer over the network, the 
second message directed to an open system interconnect (OSI) layer 7 process on the 

20 customer computer, the second message comprising an address for contacting the 
apparatus over the network using a second network connection having a second 
latency lower than the first latency. 

35. The apparatus of claim 33, wherein means for performing a multi-bid foreign 
exchange process further comprises means for straight through transfer of settlement 
25 information between the customer and corresponding dealer of a bid selected by the 
customer. 



36. A computer data signal embodied in a carrier wave comprising: 
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a computer program for mu]ti-bid foreign exchange execution over a network, 
the computer program comprising: 

a set of instructions for receiving a request for a bid on foreign exchange 
from a customer having a corresponding customer computer, the 
5 request received over the network; 

a set of instructions for identifying a plurality of computers to receive the 
request, the plurality of computers corresponding to dealers, each 
corresponding dealer having a relationship with the customer; 
a set of instructions for supporting a multi-bid foreign exchange execution 
0 for the request between the customer computer and the plurality of 

dealer computers over the network, the set of instructions enforcing 
time limits associated with multi-bid foreign exchange execution and 
monitoring latency over the network. 
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